SD - Surya - Damodhier - 2016-09-12 - 28002 - Spec - Fix counter on rescheduling (Dan by 2016-09-23) #OrderEntry

SPECIFICATIONS

28002 - Spec - Fix counter on rescheduling


Purpose

Fix counter on rescheduling.

Admin Info

Purpose
 Fix counter on rescheduling
Requested By
 Dan Brennan
Spec Created By
 Surya Basa
Spec Created Date
 09/14/2016
Spec QA by
 Surya Basa
Objects
 /AFS/SDV03V02
TVARVC
ZME_PURCHDOC_POSTED
Document Status
 Completed


Estimates


Sl.No
 Activity
 Estimation in Hours
1
 Research
 12
2
 Documentation
 08
3
 Development/ Config
 36
4
 Unit test in DEV
 12
5
 Unit test in QUA
 12
6
 Other activity

TOTAL
 80

References

Prior Tickets

[Provide links of prior associated Spec / Break Fix BOSS document(s)]

SD - Surya - Damodar - 2016-07-08 - 27571 - Service Request - Rescheduling Plant Maintenance Activity (Dan by 2016-07-10)
SD-Deepak-Damodhier- 2015-12-18 - 23716 - Spec - Update of Rescheduling Program (Dan by 2016-04-29)

Documents

[Attach any document(s) received for the requirement(s)]

TVARVC Counter.docx
TVARVC_Del_List.xlsx


Spec Changes

[List the changes made to program after the approval of the original requirement along with the Date on which the change request was received and the name of the initiator]

Sl.
 Change Details
 Requested By
 Requested On
 Notes if any
1
 Post processing program bug
 Jeff Mau
 9/19
 Approx 14hrs for DEV and Testing




















Functional Requirement

Purpose/WHY:

[Explain the purpose of the project and the reason why this requirement has come]

The counter length in the TVARVC table is restricted to 4 meaning a max of 9999 materials can only be accommodated in the variable. Also, when the post processing runs post rescheduling, it deletes the materials from the variable that don't meet the rescheduling requirements. In the process new materials are added to the variable through the user exit by checking the last counter in the variable.

A large PO was changed using ZPO_DATE_CHANGE program which resulted in loading of new materials in excess of 10000 materials subsequently resulted in short dump as the length has exceeded.

9/19/2016
It was observed in the weekend (9/17) job run that few materials were existing in the TVARVC variable even after the job completed. Analysis of the program led to a bug that didn't delete materials even though they didn't have any open SO's. If there are any open SO's in any of the plant then the program considers it open and doesn't delete even if it were not on the designated plant.

E.g. Material X doesn't not have open SO on plant 0116 but has one on plant 0117. In this case the material is not deleted from 0116.


In Scope:
[List the activities to be included in scope]

The change is restricted only to the rescheduling program and the variables maintained in the TVARVC table.

Out of Scope:

[Out of scope activities]

Solution Summary

[Discuss this section with Requester and get approval prior to beginning work]


9/19/2016

Break-fix

NEP Data

1. Non Open SO's for the materials on TVARVC were identified.TVARVC_Del_List.xlsx
2.

Program

The issue should be resolved when the grouping of sales orders is done on specific plants and deletion should take place for the specific plants instead of looking at all plants.

There are two options to overcome the issue -

I . SAP

Provide write up with test details for the failure to execute rescheduling for large input (10K) materials. Take further action based on the feedback.

II. Ztable

1. Create a Ztable with the variable and materials.
2. Create a wrapper program around the rescheduling program that will feed the materials in sets of 5000 from the Ztable to the rescheduling program.
3. This wrapper program will have the same selection screen as rescheduling program to store the variants with the plants to be picked in the rescheduling job.
4. The program should dynamically load the materials into the Ztable and feed those to the rescheduling program if new variables/variants/plants are added.
5. Make modifications to the implementation ZME_PURCHDOC_POSTED to include the Ztable instead of TVARVC.
6. The main program/job will trigger child jobs for each set of 5K input materials and the corresponding spool and log will be updated.


Test Plan

[List test scenarios/cases to be executed here]

II. Ztable

Test ID
 Scenario
 Expected Results
SD001
 Integrity Test - Compare standard with Z prg
- 0116 variant in simulation mode with Std prg
- 0116 variant in normal mode with Z prg
 Results of the both the jobs should be consistent
SD002
 Create job with 5 variants - 0116/7/0210/80/0510 (5 steps) ; each variant 20K materials
Step - 6 should be the post processing/clean up program
 - Child jobs should be triggered for each variant
- Rescheduling should be performed on the sales orders and spool/log updated updated correctly
- Clean up program should update the Ztable by deleting materials that do not satisfy the criteria
SD003
 Run the above job - variant 0117 to be blank
 Child job should not be triggered for 0117 and the remaining
variants/steps should be processed
SD004
 Run the job in test 1 with variants 0117/0510 blank
 Child jobs should not be triggered for 0117/0510; other variants/steps
should be processed
SD005
 User Exit - Update qty/delivery date on a given PO
 Ztable should be updated with the corresponding materials
SD006
 Open SO - Open SO on 0116 and not on 0117 (different materials)
 Rescheduling should not be carried for the material on 0117 but should on 0116;
post processing prg should remove the materials from the ztable
SD007
 Open SO - Open SO on 0210 and not on 0510 for the same material; SO delivery
date outside RLT
 Rescheduling should not be carried for the material on 0510 and 0210;
post processing prg should remove the material from 0510 and not on 0210
SD008
 Credit Block - Open SO on credit block on 0210 and not on 0510 for the same
material
 Rescheduling should not be carried for the material on 0210 but should on 0510;
post processing prg should not remove the material from 0510 and 0210

Solution Details

[Provide complete technical details for configuration or programming here]
1. Created a Custom Table 'ZSD_RESCH', which can be used to store the PO Quantity/Delivry Date changes for Rescheduling with Plant and Material numbers
2. Created a Program 'ZSD_WRAPPER_RESCH' with similar selection screen of Standard Rescheduling Program, which fetches the data from Rescheduling Custom Table 'ZSD_RESCH' (based on the variant name,i.e, variant name should be saved with the plant number, for each plant one variant will be created)
3. If fetched entries are:
4. Modified Badi Implementation ZME_PURCHDOC_POSTED to store the PO Quantity/Delivery Date changes in Custom Table 'ZSD_RESCH'



Issues

[List Issues / Bugs identified in configuration or development]